Building automation systems are well known, and have advanced to the state of incorporating various sophisticated features such as the capability of reporting the fact that an alarm has occurred to an offsite location. In some cases, the systems are capable of reporting the actual alarm condition and may or may not report is generally alphanumeric, intended to go, for example, either to a printer coupled in the network of the building automation system, or via leased lines to the printer in an external service organization. Such building automation systems have been limited in their capacity to report adequate information to a remote serviceman, usually requiring that the serviceman call into the system (or to a person in the monitored building) to get more complete information as to the nature of the alarm condition. If a service person intending to respond to an alarm condition can arrive on site with the parts most likely needed to fix the problem which caused the alarm, downtime should be minimized. The remote reporting systems have not been completely effective in providing adequate and related information, and often rely on the knowledge and experience of the service personnel to obtain adequate information during the course of responding to an alarm.
As an alternative, the service personnel can respond to the alarm condition by making an onsite visit to the building to get a first-hand view of the conditions. This approach suffers the consequences potentially having the parts or tools needed for repair unavailable on site. As a further complicating factor, the delay caused by inadequately equipped service personnel (inadequately equipped both with respect to information and repair parts) attempting to fix a problem, can cause extended outages with potentially serious consequences if the failure is in building mechanical systems whose operating status is essential to one or more of the building functions.
Building automation systems have the capacity to monitor numerous building operating parameters and also have the capacity to assemble comparatively huge amounts of data for display to an attendant at a console which is centrally located in the building automation system. These types of systems pose two main problems. The first is an excess of information, in that there are so many sensors and so many parameters to be monitored, and so many "minor" alarm conditions that the console operator is inundated with information, potentially slowing his response to a real alarm condition. Many systems are set up such that any parameter which varies outside its specified limits will result in an alarm, even if that alarm has no significant potential impact on the overall building or the associated automation system. A console operator having become accustomed to such "alarms" may fail to recognize a true alarm when one occurs.
A second problem with such building automation systems is related to the first, in that the person stationed at the central console is often not the one who is familiar with the details of maintaining the monitored equipment, and thus often is not in a position to fully appreciate the significance of a true alarm. Oftentimes, the person attending the console is primarily responsible for transmitting alarm information to a remotely located service organization which then assumes the responsibility for making the repair. Thus, communication of alarm conditions to the persons ultimately responsible for fixing the conditions which caused the alarm often must be translated through the console operator who may be more or less adept at associating information which is very relevant to the ultimate user, i.e., the repair organization.
Alphanumeric computer printouts are capable of conveying much information, but often in a format which is not readily assimilated by a reader, particularly in an emergency situation. Oftentimes it is possible after the conditions which caused the alarm have been rectified, to analyze the alphanumeric computer printout and demonstrate how the information on the printout pointed to the cause of the alarm. However, in real time, when the user is presented with a printout and asked to react immediately, without adequate time for reflection or analysis, the alphanumeric printout does not always trigger a response geared to the conditions which caused it.
It might be thought useful to present alarm information in a manner, such as a graphical manner, which is more easily assimilated in a high pressure emergency situation by a person charged with reacting to the emergency. However, that approach has not apparently been taken with building automation systems. Instead, to the extent those systems have provided graphical displays of relevant information, those displays have apparently been limited to display at a central console for view by an operator, and the disadvantages of that have been explained above. With respect to remote site reporting, the primary consideration seems to have been the rapid, reliable and timely transmission of the condition of the parameters which are out of tolerance, possibly associated with additional data, but all in an alphanumeric format which can require substantial interpretation on the part of the receiver in order to anticipate the nature of the fault and type of equipment which might be required to repair it.